System and method for viewing and modifying configurable rtl modules

ABSTRACT

A configurable module editor and viewer (CMVE) reads the RTL description of a configurable module keeping track of all possible configuration options. Configuration options include pre-processor macros that are normally removed by RTL parsers. The CMVE allows users to view multiple configurations simultaneously. The CMVE assists users in editing the configurable module by presenting a simplified view of interest, while automatically propagating changes and maintaining consistency in the configurable module. The CMVE outputs updated RTL that maintains all configuration options.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority under 35 U.S.C. 119(e) from U.S.provisional application No. 62/019,360; filed Jun. 30, 2014.

TECHNICAL FIELD

This invention relates to the field of integrated circuits design and inparticular to the modification of configurable design modules. Moreparticularly the invention relates to a system, method and computerprogram product for reading a configurable design, and allowing users toview and edit the configurable design.

BACKGROUND ART

Electronic chip designers develop chips of ever increasing complexityusing more and more transistors. Complex chips are often called aSystems-on-a-chip (SOC). SOC designers frequently simplify thedevelopment task by incorporating intellectual property (IP) modulesinto their design. IP modules implement pre-defined functions, are oftendeveloped by third parties and have usually been successfully used inmultiple, earlier designs.

IP module developers make their modules configurable so that the modulecan be used in as many designs as possible. Configuration options affectthe functionality of the module and how it is implemented. IP modulesare usually written in RTL design languages such Verilog and VHDL. TheSOC designer can customize an IP module by defining parameter values andspecifying macro keyword values. Different members of the SOCdevelopment team may use different configuration options. Team memberswho emulate the design using FPGAs may use configuration options thatallow the design to be implemented on an FPGA. Team members concernedwith speed, timing and power may use different configuration options.

For many designs the SOC designer has to make significant modificationsto IP modules. IP modules typically use generic memories and have few orno options for limiting power use. The SOC designer may replace allgeneric memories defined in the IP module with memory modules customizedfor the target process. The SOC designer may wish to replacetime-critical or power-inefficient RTL constructs. The SOC designerwants to preserve the configurability of the IP module as he or shemodifies it. Modifying these configurable IP modules is often adifficult, error-prone and time-consuming task. Each modification needsto work with all possible configurations. The problem is oftencompounded because the IP module developers are typically improvingtheir IP modules and supplying periodic updates. If the SOC designerwants to use the latest version of an IP module, he or she will havere-make all of his or her changes.

Existing design tools treat RTL macros as pre-processing directives.They simplify the RTL by propagating macro values and effectively removeall reference to the macros.

SOC designers need an electronic design tool to help them modifyconfigurable modules and SOC designs.

SUMMARY DISCLOSURE

A method for the viewing and editing of configurable modules of anintegrated circuit design is, provided, which is implemented as aconfigurable module viewer and editor (CMVE) software tool run on aprogrammed computing system. The system includes a computer processorhaving access to memory storing the software tool, a computer displayfor visual representation of configurable modules in an integratedcircuit design in their multiple possible configurations, and an inputdevice for receiving user inputs of changes to the circuit design. Themethod, when the software tool is run on the computing system, begins byreceiving and storing, in the memory, a register-transfer-level (RTL)description of at least a specified portion of an integrated circuit,the received RTL description specifying at least one configurable moduleof the integrated circuit. The received RTL description may contain, forat least one configurable module, any one or more of: ifdef/undefstatements; define statements; parameter definitions; pragmas; generatestatements (ifgenerate, forgenerate); and macro usage. Configurationoptions specified in the RTL description may include pre-processormacros that are normally removed by RTL parsers.

The processor constructs, and stores in the memory, a database thatincorporates for each configurable module all configuration optionsspecified in the RTL description Constructing this database ofconfiguration options may comprise extracting the configurability ofmodules defined in the RTL description by considering allconfigurability aspects defined by any one or more of 'define, 'ifdef,generate-if, generate-for, and generate-case statements. Constructingthe database may also consider configurability aspects across 'includefiles inside another file. It may also model configurability on anypartial constructs in the RTL description.

The computer display presents a visual representation of a specifiedportion including at least one configurable module in the integratedcircuit such that, based on the stored database, multiple configurationoptions of the module are viewable simultaneously. Displaying a visualrepresentation of at least one configurable module may simultaneouslyshows all possible configurations of a module, or alternatively maypresent a simplified view of one or more possible configurations for amodule that a user selects to view at the same time. Different ones ofthe possible configurations may be displayed in a visually distinctivemanner, including one or more of component naming and color.

One or more changes to the RTL description are received as user inputfrom the input device. The user input on one or more changes to the RTLdescription may be received in the form of graphical commands, or in theform of scripts and stored macros. It may include design modificationsthat group, ungroup or move across hierarchies components, as well asdesign modifications where one or more IP instances are replaced andthose where any RTL statements that will likely generate time-criticalpaths are replaced with fast library components.

The processor using the constructed database automatically propagatesthe received changes through the RTL description in a manner thatmaintains consistency of the configurable module in all configurationoptions, such that an updated RTL description, with correspondingupdates to the database, are stored in the memory. Automaticallypropagating changes through the RTL description preservesconfigurability of modules as logic is moved around or modified by thereceived user input. Configurability on ports, parameters andconnections created from moving blocks across hierarchies in the RTLdescription are automatically propagated by the processor through theRTL description. Preferably, automatically propagating changes throughthe RTL description makes minimal modifications such that onlyconfigurability of impacted and modified areas of the RTL descriptionare changed and such that a difference utility will be able to identifywhat has been modified by comparison with the received RTL description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a sample RTL module and gives a corresponding visualinterpretation.

FIG. 2 shows a flowchart outlining steps for reading a configurablemodule, allowing a user to view and specify changes to the module andfor automatically updating the RTL.

FIG. 3 shows a flowchart block diagram of a configurable module editorand viewer.

DETAILED DESCRIPTION Reference Terms & Acronyms

Configurable Module Viewer & Editor (CMVE): A system that reads aconfigurable RTL module, produces a configurable-RTL database and allowsusers to view and edit different design configurations.

Configurable-RTL Module: An RTL module that contains configurationoptions such as 'ifdef, 'undef, 'define, parameter setting, pragmas,macros, ifgenerate and forgenerate statements.

Configurable-RTL Database: A database that includes all possible RTLobjects from all possible configurations. The RTL objects are taggedaccording to their configuration membership.

Design configuration: A specific set of objects generated under aspecific set of macro states.

Macro States: A macro can have defined or undefined state. A macro hasdefined state when specified in a “define” statement and undefined stateotherwise or when referenced in an “undef” statement. Macro states arereferenced in “ifdef” statements.

Macro Combination: A macro combination is a unique combination ofindividual macro states. For example line N of the RTL may be enabledwhen “M1 & !M2” is true, where M1 and M2 are macro names.

A configurable module editor and viewer (CMVE) reads the RTL descriptionof a configurable module keeping track of all possible configurationoptions. Configuration options include pre-processor macros that arenormally removed by RTL parsers. The CMVE creates a Configurable RTLDatabase that contains all possible objects tagged with their macrodependencies. The CMVE allows users to view multiple configurationssimultaneously. The CMVE assists users in editing the configurablemodule by presenting a simplified view of interest, while automaticallypropagating changes and maintaining consistency in the configurabledesign. The CMVE outputs updated RTL that maintains all configurationoptions.

IP module developers use the following options to write scalable andconfigurable code:

1. 'defines: Defines are used to control the parameter values at theglobal level as well as for enabling various portions of RTL at thecompile time.2. 'ifdef/'undef: This allows the designer to generate different designsfrom the same RTL file. A single module can be compiled in low-powermode or in compact area mode by enabling/disabling global defines.3. Parameters: Parameters are used to make the design more scalable.Changing the value of a parameter allows a designer to reuse the samecomponent in different situations.4. Pragmas: Pragma are typically used to guard simulation specific code,but designers have started using them in non-conventional ways to getaround the limitation/capability of the RTL language.5. Generate statements: Generate statements such as “generate-if” and“generate-for” indicate conditional instantiation of components.

The RTL “generate” statement provide a way of specifying multipleinstances of the same sub-component, connected in some regular pattern.RTL “generate” statements typically contain “for” statements forrepeated instantiation, “if” statement for conditional instantiation andother controlling statements such as “case”. For example, the followingVerilog code generates 8 buffer instances:

genvar index; generate for (index=0; index < 8; index=index+1) begin:gen_code_label BUFR BUFR_inst ( .O(clk_o(index)), // Clock buffer output.CE(ce), // Clock enable input .CLR(clear), // Clock buffer reset input.I(clk_i(index)) // Clock buffer input ); end endgenerate

FIG. 1 is an exemplary diagram 100 showing an RTL module definition 110and a visual representation of that module 120. The RTL moduledefinition 110 defines a module called Mod comp. The RTL moduledefinition 110 defines four possible inputs to the module: input_a,input_b, input_c, and input_d. Only three of these inputs will bepresent in the component implementation. If the macro M1 is enabled theinputs will be input_a, input_b and input_d, otherwise the inputs willbe input_a, input_c, and input_d. The 'ifdef M1 statement controlswhether input_b or input_c will be implemented. Similarly the 'ifdef M2statement controls whether out_d1 or out_d2 will be implemented asoutput. The visual representation 120 shows an instance of the moduleMod_comp with instance name Mod_comp_0. The visual representation 120shows all possible inputs and outputs of the module instance.

In one example, the RTL designer decides to view the design with macroM1 enabled and macro M2 disabled. The RTL designer replaces the moduleMod_comp with a new module New_comp and asks the CMVE to save the designchanges. The CMVE writes out new RTL as follows:

{grave over ( )}ifdef M1&!M2 module New_comp( input in_a, input in_b,input in_d, output out_d2 ); {grave over ( )}else module Mod_comp (input in_a, {grave over ( )}ifdef M1 input in_b, {grave over ( )}elseinput in_c, {grave over ( )}endif input in_d, {grave over ( )}ifdef M2output out_d1 {grave over ( )}else output out_d2 {grave over ( )}endif); {grave over ( )}endifThis allows the RTL designer to make a simple change to the design underconditions of interest. The CMVE automatically handles the complexity ofdefining what happens under other conditions.

FIG. 2 is an exemplary and non-limiting flowchart 200 for reading aconfigurable module, allowing a user to view the configurable module andallowing a user to edit the configurable module. In S210 the CMVE readsthe RTL design file or files that define a configurable module. The CMVEmakes note of all non-macro configuration options such as pragmas andparameter definitions. In S220 the CMVE determines all macrocombinations. The CMVE identifies all macro keywords referenced in'ifdef statements. The CMVE recognizes boolean combinations of macrokeywords e.g., 'ifdef M1&!M2 uses macro-combination M1&!M2. The CMVErecognizes nested 'ifdef statements and flattens them by ANDing theouter macro expression with the inner macro expression.

The CMVE has to capture the whole intent of the design irrespective ofthe areas which will become active under different macro combinations.The CMVE does a text based parsing of the RTL input. While parsing theRTL files the CMVE maintains a stack that keeps track of macroapplicability. This stack increases and decreases in size as the CMVEencounters 'ifdef and 'endif statements. To find out the macroapplicability for a specific RTL object, the CMVE does the ANDING ofcontents of the stack from bottom to top. For example, if the contentsof the stack are M1, M2, and M3 where M3 is the top of the stack, thenthe applicable macro condition would be M1&M2&M3. Else branches of theMacros are represent by 'else or 'ifndef in the RTL and the CMVEcaptures them in the stack using the NOT(!) operator. For example the“else” branch of 'ifndef M1 would be captured as !M1. It is possible tohave RTL files included in other RTL files. The CMVE traverses throughall the include files and ensures that the current state of the stack isextended to note the include file under consideration.

In S230 the CMVE marks each RTL object with its macro dependency. TheCMVE does this by generating a data structure that associates a boolean,macro expression with each RTL object. In S240 the CMVE optimizes itslist of macro combinations by removing duplicates and unusedcombinations.

The CMVE allows a user to specify macros to be ignored. The user may notwant to maintain configurability in terms of those macros. Ignoringmacros will make the CMVE faster by reducing the number of macrocombinations.

The CMVE further optimizes the macro-combinations generated by theparser in S220 as follows:

1) Macro-combinations which cannot be valid are removed. For example,the macro X can be defined in the RTL and in CMVE run-time parameters(e.g., on the CMVE command line). The macro-combination !X&Y cannot bevalid if X is defined.2) Macro-combinations depending on undefined macros e.g., (!X&!Y or !Z)and (!A&!B) are combined into one macro-combination where all macros areundefined, e.g., (!A&!B&!X&!Y&!Z).3) Macro-combinations having macros to be ignored are removed.

Many RTL designs contain syntactic errors in unused or rarely-usedmacro-combinations. The CMVE reports those macro-combinations whichresult into syntax errors and continues to process macro-combinationswith valid syntax. If the CMVE discovers a syntax error in the casewhere all macros are undefined it tries successive macro-combinationsuntil it finds a macro-combination without syntax errors. After findinga successful macro-combination, the CMVE attempts to merge the remainingmacro-combination.

The complete SOC RTL can have hundreds of unique macro combinations. TheCMVE maintains a database containing RTL objects for everymacro-combination. This database is large for a complete large-scale SOCdesign. The user can process a sub-set of the complete SOC design tolimit the size of the CMVE database. For example, the user may want totreat the top level design and only a few specific sub-systems. The userspecifies the full RTL design of the sub-systems of interest andspecifies the interface definition for the other sub-systems. The CMVEensures that unique macro combinations which are only part of theinterface-only sub-systems are not considered for merging.

The CMVE has an option where it can ignore unique global macrocombinations. A global macro combination is a macro combination presentin the global scope, which is outside a module boundary.

In S250 the CMVE starts to loop over the possible macro combinations. Onthe first iteration at S250 the CMVE identifies the first macrocombination. On subsequent iterations the CMVE identifies the next macrocombination. In S250 the CMVE instantiates the RTL objects associatedwith the identified macro combination. The CMVE adds the RTL objects toa database and tags them with the identified macro combination. In 5260the CMVE checks if there are more macro combinations. If the CMVE findsmore macro combinations it loops back to S250. If the CMVE does not findmore macro combinations it proceeds to S270.

It is possible for an RTL object to be active under more than one macrocombination, and also the properties of the same object can differ indifferent macro combinations. When an object is visible under only onemacro combination the CMVE tags it with that particular macrocombination. If an object is visible in more than one macro combinationthe CMVE tags it with properties for each of the different macrocombinations. The following Verilog example illustrates this:

module uart (  {grave over ( )}ifdef FPGA input [3:0] interrupt; {graveover ( )}else  input [7:0] interrupt; {grave over ( )}endif );In the above example, the IP module called uart has a port calledinterrupt with different width based on whether this is to beimplemented with the FPGA macro defined or not defined. The CMVE findsthese kind of objects and calls them partial constructs. This is incontrast to the scenario where an entire RTL construct (e.g., an entireport or user instance) is conditionally instantiated.

In S270 the CMVE displays the configurable module in a schematic form.The CMVE displays all possible configurations and highlights thosecomponents, pins and nets that are macro dependent. In one embodimentthe CMVE displays macro dependent module instances, pins, parameters andnets in different colors. In another embodiment the CMVE addsidentifying text to the component, pin or net name e.g., comp_1(M1&!M2). The CMVE allows users to select alternate views thatcorrespond to different macro combinations. For example, the user canrequest a view corresponding the macro expression M1&!M2. The CMVEallows users to modify the configurable module. The CMVE provides theusual schematic editing capabilities of adding, moving & deletingcomponents, pins and nets. In addition to the usual editing capabilitiesthe CMVE keeps track of the macro dependencies of added components. TheCMVE allows users to group and ungroup components. Grouping componentsintroduces a new hierarchical level. For example, a user may replace ageneric memory component with multiple technology-specific memorymodules and then group the multiple technology-specific memory modulesinto a new module. The CMVE allows users to move logic blocks from onehierarchy level to another. The CMVE keeps track of all possibleconfigurations and reports inconsistencies in any configuration.Inconsistencies include unconnected pins and dangling nets.

The CMVE allows script-language editing of its database using languagessuch as the Tool Command Language (TCL). The CMVE provides scriptlanguage commands that implement all of the schematic editingcapabilities. The CMVE allows users to execute script commands. The CMVEallows users to record schematic editing commands as script commands.Users can use script commands to simplify repetitive commands. SOCdesigners can use script commands to repeat IP module customization whenthey receive a new version of an IP module.

The CMVE preserves “generate-if” and “generate-for” constructs presentin the RTL and allows a user to edit those structures while stillpreserving the “generate-if” and “generate-for” structures in theupdated RTL. The CMVE creates a virtual hierarchy for eachgenerate-block present in the RTL. The user specifies modifications atan abstract level (e.g., moving logic from one hierarchy to another,grouping/ungrouping logic or swapping an instantiated memory within agenerate-for structure with another kind of memory IP). The CMVE takesinformation from this abstract level and perform all the modificationswhile maintaining the design configurability in the generated RTL.

The CMVE creates and maintains tagged information about all instancespresent inside or generated by a for-loop inside a generate-block. TheCMVE keeps track of the conditions controlling such instances. The CMVEallows a user to edit the connectivity of those instances and also toupdate a master for those instances and replace it with a new IP master.For example, users can replace third-party memories present inside a“generate” construct with their own internal memories. A user can editthe “generate” virtual hierarchy in the CMVE schematic editor. A usercan also edit the virtual hierarchy using TCL commands. After masterreplacement and connectivity editing, the CMVE uses the taggedinformation to regenerate the modified generate structure.

In case of “generate-if” structures, the CMVE reads all possible pathsincluding true and false paths. The CMVE reads one “generate-if” path ata time and tags RTL instances, connections and behavioral logic presentin that path accordingly. When the CMVE reads the next path it mergesthe RTL logic present in that path with that of the previous path RTLlogic but tags it differently. The CMVE repeats this process for all thepaths. Finally, the CMVE displays a merged views of all “generate-if”paths in its schematic and allows a user to edit instance connectionsand the master present in each path.

In S280 the CMVE writes the modified database back out as RTL. The CMVEmaintains all configuration options. The CMVE writes macro-dependentconfiguration options using 'ifdef statements and writes out otherconfiguration options such as pragmas, 'define and parameter values. TheCMVE preserves the original RTL look and feel as much as possible.

The generation of the RTL to ensure that the look-n-feel is preserved isdone in a 2 step process. In the first step, the CMVE reads the RTL withall its configurability and creates a database. While the user performsmultiple modifications on this database the CMVE ensures thatconfigurability is maintained in the modified database. The CMVE keepstrack of all the changes to the database. This change information ispassed to a second stage process which reads the RTL through a textparser and incrementally re-writes the lines where modifications havehappened with the new changes. This ensures that the generated RTL has alook-n-feel which is very close to the original RTL and the user can usea difference utility to find out what has changed.

FIG. 3 is an exemplary and non-limiting diagram 300 showing aConfigurable Module Viewer & Editor (CMVE) 320. A central processingunit (CPU) or microprocessor 304 loads and runs the CMVE software 320.Data storage 302 is accessible to the processor 304 and storesconfigurable RTL design files 310 representing a circuit description.The Configurable RTL Database 340, editing scripts 370 as well as theupdated RTL design files 350 could likewise be stored in the datastorage 302. The system 300 further includes user-interactiveinput/output devices, including at least one input device 330 anddisplay 360.

The CMVE 320 runs as an application program on a central processing unit(CPU) 304. The CMVE 320 interacts with a user through an input device330 and a display 360. The CMVE 320 displays a visual representation ofthe configurable module on the display 360. A logic designer specifiesCMVE inputs, starts the CMVE, controls viewing and edits theconfigurable module using the input device 330. The CMVE 320 reads theconfigurable module RTL 310. The CMVE 320 creates the Configurable RTLDatabase 340 and reads/updates the Configurable RTL Database 340 whencommanded to do so. The CMVE 320 writes the Updated Configurable RTL 350in response a user's request to save the database edits though inputdevice 330. The CMVE 320 executes editing scripts 370 in response touser's requests through input-device 330. The CMVE 320 may save commandsto the editing scripts 370 in response to user requests through inputdevice 330.

The embodiments disclosed herein can be implemented as hardware,firmware, software, or any combination thereof. Moreover, the softwareis preferably implemented as an application program tangibly embodied ona program storage unit or computer readable medium. The applicationprogram may be uploaded to, and executed by, a machine comprising anysuitable architecture. Preferably, the machine is implemented on acomputer platform having hardware such as one or more central processingunits (“CPUs”), a memory, and input/output interfaces. The computerplatform may also include an operating system and microinstruction code.The various processes and functions described herein may be either partof the microinstruction code or part of the application program, or anycombination thereof, which may be executed by a CPU, whether or not suchcomputer or processor is explicitly shown. In addition, various otherperipheral units may be connected to the computer platform such as anadditional data storage unit and a printing unit. Furthermore, anon-transitory computer readable medium is any computer readable mediumexcept for a transitory propagating signal.

What is claimed is:
 1. A method implemented as a configurable moduleviewer and editor (CMVE) software tool run on a programmed computingsystem for the viewing and editing of configurable modules of anintegrated circuit design, comprising: receiving and storing, in amemory accessible to a computer processor, a register-transfer-level(RTL) description of at least a specified portion of an integratedcircuit, the received RTL description specifying at least oneconfigurable module of the integrated circuit; constructing by thecomputer processor, and storing in the memory, a database thatincorporates for each configurable module all configuration optionsspecified in the RTL description; displaying on a computer display avisual representation of a specified portion including at least oneconfigurable module in the integrated circuit such that, based on thestored database, multiple configuration options of the module areviewable simultaneously; receiving from a user input one or more changesto the RTL description; and automatically propagating, by the processorusing the database, of the received changes through the RTL descriptionin a manner that maintains consistency of the configurable module in allconfiguration options, such that an updated RTL description, withcorresponding updates to the database, are stored in the memory.
 2. Themethod as in claim 1, wherein the received RTL description contains, forat least one configurable module, any one or more of: ifdef/undefstatements; define statements; parameter definitions; pragmas; generatestatements, such as ifgenerate and forgenerate statements; and macrousage.
 3. The method as in claim 1, configuration options specified inthe RTL description include pre-processor macros that are normallyremoved by RTL parsers.
 4. The method as in claim 1, whereinconstructing a database of configuration options comprises extractingthe configurability of modules defined in the RTL description byconsidering all configurability aspects defined by any one or more of'define, 'ifdef, generate-if, generate-for, and generate-casestatements.
 5. The method as in claim 4, wherein constructing thedatabase of configuration options also considers configurability aspectsacross 'include files inside another file.
 6. The method as in claim 4,wherein construction a database of configuration options also modelsconfigurability on partial constructs in the RTL description.
 7. Themethod as in 1, wherein displaying a visual representation of at leastone configurable module simultaneously shows all possible configurationsof a module.
 8. The method as in claim 1, wherein displaying a visualrepresentation of at least one configurable module presents a simplifiedview of one or more possible configurations for a module that a userselects to view at the same time.
 9. The method as in claim 1, whereinin displaying a visual representation of at least one configurablemodule presents different ones of the possible configurations in avisually distinctive manner, including one or more of component namingand color.
 10. The method as in claim 1, wherein user input on one ormore changes to the RTL description is received in the form of graphicalcommands.
 11. The method as in claim 1, wherein user input on one ormore changes to the RTL description is received in the form of scriptsand stored macros.
 12. The method as in claim 11, wherein graphicaledits are saved in a script in a manner that allows the processorexecuting the CMVE tool to automatically apply those edits to a newrevision of the configurable module.
 13. The method as in claim 1,wherein user input on one or more changes to the RTL descriptionincludes design modifications that group, ungroup or move acrosshierarchies components.
 14. The method as in claim 1, wherein user inputon one or more changes to the RTL description includes designmodifications where one or more master instances are replaced.
 15. Themethod as in claim 1, wherein user input on one or more changes to theRTL description includes design modifications where any RTL statementsthat will likely generate time-critical paths are replaced with fastlibrary components.
 16. The method as in claim 1, wherein automaticallypropagating changes through the RTL description preservesconfigurability of modules as logic is moved around or modified by thereceived user input.
 17. The method as in claim 16, whereinconfigurability on ports, parameters and connections created from movingblocks across hierarchies in the RTL description are automaticallypropagated by the processor through the RTL description.
 18. The methodas in claim 1, wherein automatically propagating changes through the RTLdescription makes minimal modifications such that only impacted andmodified areas of the RTL description are changed and such that adifference utility will be able to identify what has been modified bycomparison with the received RTL description.
 19. A programmed computersystem for running a configurable module viewer and editor (CMVE)software tool that provides for viewing and editing of configurablemodules of an integrated circuit design, the system comprising: acomputer memory storing the CMVE software tool, aregister-transfer-level (RTL) description of at least a specifiedportion of an integrated circuit, the RTL description specifying atleast one configurable module of the integrated circuit, and aconstructed database that incorporates for each configurable module allconfiguration options specified in the RTL description; a computerprocessor having access to the computer memory and running the softwaretool; a computer display presenting a visual representation of aspecified portion including at least one configurable module in theintegrated circuit, such that multiple configuration options of themodule are viewable simultaneously; and an input device for receiving asuser input one or more changes to the RTL description; wherein thecomputer processor when running the CMVE software tool constructs thedatabase from a received RTL description, directs the display of thevisual representation of the at least one configurable module inmultiple configuration options, receives any user input, andautomatically propagates, using the database, the received changesthrough the RTL description in a manner that maintains consistency ofthe configurable module in all configuration options, such that anupdated RTL description, with corresponding updates to the database, arestored in the memory.